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ABSTRACT 

This  report  describes  a  database  system  developed  by  the  Air  Operations  Division  (AOD) 
for  aircraft  flight  dynamic  models.  A  new  database  format  has  been  established  to  meet  AOD's 
flight  dynamic  and  performance  requirements.  A  program  has  been  written  to  create  program 
soiurce  code  to  read  and  interpolate/extrapolate  data  stored  in  the  database  format.  The  major 
advantage  of  the  new  database  format  is  that  all  the  information  required  to  read  and  interpo¬ 
late/extrapolate  a  data  set  is  contained  within  the  database.  A  typical  example  of  the  database 
format,  technical  descriptions  of  the  syntax,  methods  of  interpolation/ extrapolation,  method  of 
database  interfacing,  and  procedure  for  database  use  are  given. 
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A  Database  Compiler  for  Flight  Dynamic  Applications 


EXECUTIVE  SUMMARY 

A  database  compiler  has  been  developed  by  the  Air  Operations  Division  (AOD)  for  use  in  con¬ 
structing  aircraft  flight  dynamic  and  performance  models  and  a  database  format  has  been  estab¬ 
lished  to  meet  the  AOD  requirements  of  both  modelling  activities.  A  program  has  been  written 
to  create  program  source  code  to  read  and  interpolate/ extrapolate  data  stored  in  this  database 
format.  The  major  advantage  of  this  format  is  that  all  the  information  required  to  read  and 
interpolate/ extrapolate  a  data  set  is  contained  within  the  database.  A  t5q?ical  example  of  the 
database  format,  technical  descriptions  of  the  S5mtax,  method  of  interpolation/extrapolation, 
method  of  database  interfacing,  and  procedure  for  database  compiling  is  given. 

The  major  benefit  of  the  database  compiler  system  within  AOD  is  the  introduction  of  a  common 
database  format  and  interpolation  system.  This  format  has  been  adopted  by  Flight  Mechanics 
and  Performance  for  all  new  software  and  any  newly  developed  programs  that  require  data  in¬ 
terpolation  can  use  this  system.  This  commonality  has  greatly  improved  the  rate  at  which  flight 
dynamic  and  performance  model  databases  may  be  produced,  as  the  data  access  and  interpo¬ 
lation/  extrapolation  routines  have  already  been  taken  care  of  by  the  database  compiler.  The 
compiler  also  represents  a  faster  and  more  efficient  method  of  accessing  the  required  databases. 

The  database  compiler  is  currently  being  used  by  a  variety  of  aircraft  flight  dynamic  and  per¬ 
formance  models.  The  database  compiler  has  been  used  to  interpolate/extrapolate  the  aerody¬ 
namic  data  for  a  basic  trainer  spinning  model,  an  F-lllC  flight  dynamic  model,  and  the  perfor¬ 
mance  characteristics  of  the  F/ A-18.  The  use  of  the  database  format  and  compiler  is  not  confined 
to  these  specific  examples  drawn  from  Air  Operations  Division.  It  can  be  used  by  any  applica¬ 
tion  that  requires  the  interpolation/ extrapolation  of  multi-dimensional  data. 
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1  INTRODUCTION 


This  report  describes  the  format  used  in  developing  the  aircraft  flight  dynamic  model  databases 
within  the  Air  Operations  Division  (AOD)  at  the  Aeronautical  and  Maritime  Research  Labo¬ 
ratory  (AMRL)  of  the  Defence  Science  and  Technology  Organisation  (DSTO).  A  similar  format 
was  originally  employed  by  the  US  Naval  Air  Warfare  Center  Aircraft  Division  (NAWC-AD)  [1] 
for  their  F/A-18  flight  dynamic  model.  This  format  has  been  extended  and  a  compiler  called 
dbc  produced  to  create  FORTRAN  77  [2]  or  C  [3]  programming  language  routines  to  read  and 
interpolate /extrapolate  data.  The  compiler  has  been  built  aroimd  an  n-dimensional  interpola¬ 
tion/extrapolation  routine.  The  advantage  of  this  particular  database  format  is  that  all  the  infor¬ 
mation  required  to  read  and  interpolate /extrapolate  a  data  set  is  contained  within  the  database 
itself.  The  database  format  uses  ASCII  character  words  that  describe  and  direct  the  means  by 
which  data  will  be  evaluated.  This  format  has  been  used  to  develop  databases  for  a  flight  dy¬ 
namic  model  of  a  spinning  aircraft  based  on  a  basic  trainer  [4],  an  update  to  the  F-lllC  flight 
dynamic  model  [5],  a  flight  dynamic  model  for  the  MK-82  store  [6],  and  for  an  aircraft  perfor¬ 
mance  estimation  utility  [7]  for  the  F/A-18  and  F-lllC.  A  typical  example  of  the  database  format 
is  given  in  Appendix  A.  This  example  is  used  in  section  5  to  describe  the  procedure  for  read¬ 
ing  the  database.  A  technical  description  of  the  syntax,  method  of  interpolation/ extrapolation, 
method  of  database  interfacing,  and  procedure  for  compiling  the  database  format  is  given  in  the 
following  sections. 

Note  that  this  report  describes  the  functionality  of  the  database  compiler  dbc  for  version  2.6. 
The  compiler  is  downwards  compatible  and  will  read  dbc  database  formats  of  earlier  versions. 


2  DATABASE  FORMAT  AND  COMPILER  HISTORY 

The  database  format  and  compiler  described  within  this  document  was  developed  as  part  a 
flight  dynamic  model  of  a  spinning  aircraft  based  on  basic  trainer  [4].  Large  amounts  of  wind- 
tunnel  data  had  to  be  read  and  interpolated  to  provide  the  aerodynamic  force  and  moment  in¬ 
formation  for  the  model's  equations  of  motion.  Aerodynamic  data  was  available  from  three 
sources  for  the  basic  trainer;  static  wind-tunnel  data,  rotary  balance  wind-tunnel  data,  and  data 
from  a  line  vortex  model.  This  data  was  to  be  formed  into  three  separate  databases. 

A  database  format  was  required  that  was  easy  to  interpret  and  generate.  All  database  formats 
used  within  AOD  for  existing  flight  dynamic  models  were  assessed.  None  of  these  database 
formats  allowed  the  functionality  of  the  data  to  be  intuitively  interpreted  from  the  database 
source  (i.e.  the  formats  did  not  include  information  about  how  the  data  is  to  be  read  or  ma¬ 
nipulated).  Evaluatingflight  dynamic  models  acquired  from  outside  DSTO,  the  F/A-18  flight 
dynamic  model  developed  by  NAWC-AD  [1]  had  a  format  for  its  flight  data  database  that  was 
simple  to  read  and  imderstand.  The  basis  of  the  format  is  the  definition  of  functions  that  are 
to  be  interpolated.  The  ftmctions  define  a  set  of  independent  variables  and  consequently  the 
number  of  points  the  function  holds  for  interpolation.  This  is  the  format  that  was  adopted  and 
improved  upon  and  is  described  is  section  3. 

Once  a  database  format  was  established,  a  program  was  required  to  read  the  data  and  provide 
interpolation  routines  to  access  the  database.  The  database  routine  library  had  to  be  indepen¬ 
dent  of  the  flight  dynamic  model  so  that  it  could  be  easily  adapted  to  other  flight  dynamic  mod¬ 
els.  The  NAWC-AD  F/A-18  flight  dynamic  model  has  database  manipulating  routines,  how¬ 
ever  they  were  written  using  DEC  VMS-specific  functions.  It  was  therefore  decided  to  write 
database  read  and  interpolation  routines  that  were  independent  of  operating  system  type  and 
would  ultimately  be  used  with  UNIX  and  DOS  operating  systems. 
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The  first  implementation  of  the  database  read  and  interpolation  routines  was  a  set  of  FORTRAN  77 
routines  that  read  the  database  at  rim-time  and  generated  a  table  of  user-defined  dependent 
variables.  This  process  was  slow  due  to  the  interpretation  of  an  ASCII  file.  Interpolation  was 
carried  out  with  several  steps.  The  name  of  the  user-defined  dependent  variable  was  passed  to 
the  interpolation  routine.  The  dependent  variable  would  then  be  searched  for  within  the  lookup 
table.  The  data  would  then  be  passed  to  the  interpolation  routine  and  a  value  returned.  Several 
annoying  problems  were  encoimtered  with  this  library  of  routines: 

•  Interpolation  was  slowed  by  the  need  to  look  up  dependent  variable  names  within  a  table 
of  user  defined  dependent  variables. 

•  Database  storage  arrays  were  pre-allocated  and  were  memory  inefficient,  i.e.  the  data  were 
not  dynamically  assigned  at  run-time  and  data  could  not  be  unloaded  from  memory. 

•  Database  storage  arrays  were  defined  in  COMMON  BLOCKS  that  the  user  had  to  edit  to 
define  data  limits.  This  introduced  problems  due  to  the  user  not  understanding  the  re¬ 
quirements  of  the  COMMON  BLOCKS. 

The  obvious  solution  was  to  write  a  program  that  would  generate  program  source  code  spe¬ 
cific  to  particular  data.  This  eliminated  all  the  problems  above  and  allowed  greater  flexibility 
with  the  use  of  the  database  technique.  Section  4  describes  the  use  of  the  developed  compiler. 
This  compiler  has  been  written  to  generate  database  read  and  interpolation  routines  for  C  and 
FORTRAN  77  programming  languages  for  the  UNIX,  DOS,  and  Microsoft  Windows  operating 
environments. 


3  DATABASE  FORMAT  DESCRIPTION 


The  database  format  consists  of  an  ASCII  character  file  of  descriptive  words  that  provide  di¬ 
rectives  by  which  defined  dependent  variables  are  to  be  read  and  interpolated.  An  example 
database  is  given  in  Appendix  A.  The  database  format  allows  the  definition  of  a  dependent  vari¬ 
able,  say  X,  to  be  tabulated  at  discrete  values  of  a  number  of  independent  variables  yi  i=i,n-  We 
wish  to  obtain  the  value  of  x  at  values  of  yi  not  corresponding  to  those  for  which  x  is  tabulated. 
That  is  we  wish  to  evaluate 


/(yi,y2,y3,  ■ 

-  Vn) 

(1) 

,  y3  =  y'a,  ■ 

II 

(2) 

In  the  nomenclature  of  the  database  compiler,  THRUPUT  defines  the  names  of  the  dependent 
and  independent  variables.  CONBPT  and  VARBPT  define  the  values  of  the  independent  vari¬ 
ables  yi  for  which  values  of  dependent  variable  x  is  tabulated.  POINTS  defines  the  values  of  the 
dependent  variable  x  for  all  tabulated  values  of  the  independent  variable  yi. 

These  descriptive  words  are  termed  reserved.  That  is  to  say  they  cannot  be  used  as  database  vari¬ 
able  names.  The  reserved  words  are  not  case-sensitive  and  are  explained  in  detail  in  the  following 
sections.  Brief  definitions  are  as  follows: 

TITLE:  this  directive  defines  the  title  for  a  specific  data  set. 

THRUPUT:  this  directive  defines  a  user-dependent  variable  as  a  function  of  independent  vari¬ 
ables  for  interpolation. 
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CONBPT:  this  directive  defines  values  of  the  independent  variables  that  have  data  values  with 
a  constant  step. 

VARBPT:  this  directive  defines  values  of  independent  variables  that  have  data  values  with  a 
variable  step. 

POINTS:  this  directive  defines  the  values  of  an  independent  variable  for  all  tabulated  values 
of  the  independent  variables. 


A  single  line  in  the  ASCII  file  must  not  exceed  512  characters.  Data  past  the  512th  character  will 
not  be  read.  No  warning  is  given  if  this  occurs.  Comments  in  the  database  file  are  denoted  by 
special  characters  in  the  first  column  of  the  line.  Special  characters  are  considered  to  be  any  of 
the  following: 

~!@#$%^&*  ()<>{}  [] 

It  is  suggested,  however,  that  for  consistency  only  one  should  be  used  in  a  somce  database  file. 
Preferred  characters  are  ! ,  #,  or  %  since  they  are  consistent  with  usage  in  many  operating  sys¬ 
tems  (e.g.  UNIX). 

The  following  conventions  and  symbols  are  used  in  the  text  to  describe  the  form  of  the  database 
file  directives: 

UPPER  CASE 

lower  case 

[] 

{} 

I 

0 


3.1  TITLE  Directive 
Function 

Sets  a  title  to  classify  the  type  of  data  to  follow. 


Upper  case  letters  and  words  are  to  be  written  as  shown,  ex¬ 
cept  where  noted  otherwise. 

Lower  case  abbreviations  and  words  represent  characters  or 
numerical  values  that  are  to  be  defined. 

Brackets  are  used  to  indicate  optional  items. 

Braces  surrounding  two  or  more  items  indicate  that  at  least 
one  of  the  items  must  be  specified. 

The  or  symbol  separates  two  or  more  optional  items. 

An  ellipsis  indicates  that  the  preceding  optional  item(s)  may 
appear  more  than  once  in  succession. 

A  pair  of  parentheses  enclose  entities  that  must  be  written 
as  shown. 


Syntax 

TITLE  title-string 
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Example 


TITLE  F-lllC  Longitudinal  Flight  Data 
title  Binary  Shift  Data 

Method  of  Operation 

The  title  title-string  should  be  a  general  description  of  the  data  that  are  to  follow.  Any  number 
of  TITLE  directives  may  be  used  in  a  file,  including  none.  The  title  declared  will  be  displayed  to 
standard  output  when  the  database  is  being  read  into  the  user's  program.  There  is  no  limit  to 
the  length  of  the  title  string  except  that  defined  by  the  maximum  number  of  characters  per  line 
of  database  source  (512  characters). 


3.2  THRUPUT  Directive 
Function 

Defines  the  name  and  functionality  of  a  user  defined  dependent  variable  to  be  interpolated.  All 
dependent  and  independent  variables  names  are  defined. 


Syntax 

THRUPUT  var(  bpt  [,  bpt]  ...),ext 
where: 

var  is  the  name  of  a  dependent  variable  to  be  defined. 

bpt  is  the  name  of  a  independent  variable  to  be  defined  using  the  VARBPT  or  CONBPT  direc¬ 
tives.  A  bpt  name  of  NULL  has  a  special  meaning  and  is  described  below. 

ext  is  an  extension  string  to  append  to  the  dependent  variable  name  var. 


Example 

thruput  Cma(  alpha,  alt,  mach) , fit 
THRUPUT  z  (  X,  y) 

Method  of  Operation 

The  THRUPUT  directive  is  used  to  define  the  way  in  which  a  dependent  variable  is  to  be  read 
and  interpolated  using  a  set  of  independent  variables.  The  dependent  variable  name  var  must 
appear  with  a  POINTS  directive  later  in  the  database  file  and  it  will  hold  the  values  to  be  interpo¬ 
lated.  The  dimensionality  of  the  dependent  variable  var  is  defined  with  independent  variables 
bpt.  Any  number  of  independent  variables  can  be  defined.  Each  independent  variable  must  ap¬ 
pear  with  a  CONBPT  or  VARBPT  directive  later  in  the  database  file  and  it  will  hold  data  defin¬ 
ing  the  bounds  of  the  interpolation.  If  no  data  is  required  for  the  independent  variable,  then  the 
independent  variable  name  must  be  NULL. 
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The  NULL  directive  is  used  when  a  THRUPUT  dependent-variable  needs  to  appear  as  though  it 
has  higher  dimensionality  than  the  data  indicate.  It  is  possible  that  a  program  may  require  to  al¬ 
low  the  user  to  choose  between  several  database  sources,  e.g.  an  F/ A-18  or  an  F-lllC  database, 
as  shown  is  section  4.7.2.  The  database  would  be  easier  to  access  if  common  THRUPUT  de¬ 
pendent  variables  were  accessed  with  the  same  argiiments.  For  example,  an  F/A-18  database 
may  have  lift  coefficient  as  a  ftmction  of  angle  of  attack,  stabilator  and  rudder  deflections,  while 
the  F-lllC  database  may  have  lift  coefficient  as  a  function  of  the  same  independent  variables  as 
well  as  wing  sweep.  To  make  both  aircrafts'  lift  coefficient  variables  have  common  calling  ar¬ 
guments,  the  following  THRUPUT  definitions  could  be  employed: 

!  F-lllC  lift  coefficient 

THRUPUT  CL(  AOA,  STAB,  RUDD,  SWEEP),  Fit 

!  F/A-18  lift  coefficient 

THRUPUT  CL{  AOA,  STAB,  RUDD,  NULL), Fit 

No  sweep  information  need  appear  in  the  POINTS  directive  for  the  F/A-18  database.  The  de¬ 
pendent  variable  would  be  treated  as  a  four-dimensional  variable  and  not  five-dimensional. 
The  dependent  variables  would  be  accessed  in  the  following  manner. 

!  F-lllC  CL_Flt  call 

CL  =  CL_Flt(  alpha,  stab,  rudder,  sweep) 

!  F/A-18  CL_Flt  call 

CL  =  CL_Flt(  alpha,  stab,  rudder,  sweep) 

For  the  F/A-18  routine  call,  the  independent  variable  sweep  would  not  be  used  in  the  interpo¬ 
lation  of  CL_Flt . 

Method  of  Interface 

The  THRUPUT  directive  also  defines  the  interface  between  the  interpolation  variable  to  the  user 
source  code.  When  the  database  is  compiled,  the  name  of  the  FORTRAN  77  or  C  function  gen¬ 
erated  by  the  THRUPUT  directive  is  made  up  from  the  dependent  variable  name  var  and  its 
extension  name  ext.  The  C  or  FORTRAN  77  interpolation  function  name  would  have  the  form 
var_ext.  By  convention,  extension  is  used  to  indicate  the  form  of  data  being  used.  If  the  data 
were  for  example  flight  data,  an  extension  of  fit  could  be  used,  similarly  an  extension  of  wt 
or  cf  d  could  be  used  to  denote  wind-tunnel  or  computational  fluid  dynamic  data  respectively. 
If  the  extension  name  ext  is  not  given,  then  the  interpolation  function  name  would  be  var.  For 
example,  the  THRUPUT  directives 

THRUPUT  Cina(  alpha,  alt,  mach)  ,  f It 
THRUPUT  Cmq(  alpha,  alt,  mach)  ,wt 
THRUPUT  Cnr(  alpha,  alt,  mach) 

would  generate  a  soiuce  code  interface  called 

Cma_f  It 
Cmq_wt 


and  would  be  accessed  in  a  FORTRAN  77  program  as 


real  alpha,  alt,  mach,  Cma,  Cma_flt 

alpha  =  10.0 
alt  =  25000.0 
mach  =  0.68 

Cma  =  Cma_f It (  alpha,  alt,  mach) 
write ( 6 , * ) ' Cma  =  ',  Cma 


or  in  a  C  program  as 


# include  "dbcinclude . h" 

float  alpha,  alt,  mach,  Cma; 


alpha  =  10.0; 
alt  =  25000.0; 
mach  =  0.68; 

Cma  =  Cma_flt(  &alpha,  &alt, 
printf(  "Cma  =  %f\n",  Cma) ; 


&mach)  ; 


Note  that  in  the  FORTRAN  77  code,  the  database  interface  function  should  be  defined  with  a 
REAL  statement.  In  C  programs  however,  an  #  include  statement  is  used  to  incorporate  a  file 
that  contains  all  the  function  prototypes  and  defines  for  the  database  interfaces.  This  include 
file  is  created  during  the  compilation  of  a  database  and  will  usually  have  a  name  of  the  form 
databasesourcemme.h.  See  section  4.6  for  more  information  on  program  coding. 


3.3  CONBPT  and  VARBPT  Directive 
Function 

Defines  a  data  set  to  be  used  as  an  interpolation  axis  for  a  user-defined  independent  variable. 


Syntax 

bpt  CONBPT  start  end  step  /  [option]  ... 
bpt  VARBPT  Start  [  data  .  .  .  ]  /  [option]  .  .  . 

where: 

bpt  is  the  independent  variable  name, 
start  is  the  start  data  point, 
data  is  an  intermediate  data  point, 
end  is  the  last  data  point. 

step  is  the  step  size  to  use  between  start  and  end  points  to  calculate  intermediate  points. 
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Example 


alpha  conbpt  -5.0  25.0  2/  ubl=30.0  lbl=-8.5 
beta  conbpt  -10.0,  10.0,  5/  warning=on 
X  VARBPT  0.0,  0.135,  0.275,  0.287,  0.568,  0.612, 

0.986/ 

Method  of  Operation 

The  CONBPT  and  VARBPT  directives  are  used  to  define  the  values  of  each  independent  vari¬ 
able  for  which  data  are  tabulated.  Each  independent  variable  name  appearing  in  a  CONBPT  or 
VARBPT  should  have  been  previously  defined  via  a  THRUPUT  directive  or  the  defined  inde¬ 
pendent  variable  will  not  be  used.  CONBPT  is  used  where  these  values  are  uniformly  spaced 
while  VARBPT  is  used  where  their  spacing  is  variable. 

The  values  used  for  start,  end,  data  and  step  maybe  either  REAL/ float  or  integer  type.  The  last 
data  value  must  be  terminated  with  a  forward  slash  (/). 


3.3.1  Independent  Variable  Options 

Several  options  can  be  used  with  the  CONBPT  and  VARBPT  directives  to  define  the  behaviour 

of  the  interpolation.  These  are: 

LBL  &  UBL:  specify  the  lower  and  upper  bound  limits  respectively  for  the  independent  vari¬ 
able.  If  a  value  exceeds  these  limits,  then  the  lower  or  upper  bound  limit  value  (see  below) 
is  passed  back  to  the  user  code.  If  no  LBL  or  UBL  options  are  given,  then  the  data  set  may 
be  extrapolated  to  ±oo  (or  the  machine  limit  for  these  values). 

Syntax:  ubl={limit}. 

LBV  &  UB  V:  specify  the  lower  and  upper  bound  values  to  return  when  a  lower  or  upper  bound 
limit  is  reached.  If  no  LBV  or  UBV  values  are  given,  then  the  value  returned  is  that  inter¬ 
polated/extrapolated  by  using  the  LBL  or  UBL  values.  If  no  LBL  or  UBL  values  are  given 
then  LBV  and  UBV  are  not  processed. 

Syntax:  ubv={ value}. 

WARNING:  specifies  that  warning  messages  should  be  given  when  a  lower  or  upper  bound 
limit  is  reached.  The  messages  will  appear  on  the  standard  output  device,  (normally  the 
terininal  screen).  By  default  no  warning  messages  are  displayed. 

Syntax:  waming={on,off}. 


3.4  POINTS  Directive 
Function 

Defines  the  data  set  for  a  user  defined  dependent  variable. 
Syntax 

var  POINTS  data  [data  ...] 
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where: 


var  is  the  name  of  the  user  defined  dependent  variable, 
data  are  the  values  to  be  interpolated. 


Example 

Cla  POINTS  0.00134  0.0056  0.0089  0.012  0.016  0.018/ 
z  points  1.0,  2.0,  3.0,  4.0,  5.0,  6.0,  7.0,  8.0, 
9.0,  10.0/ 


Method  of  Operation 

The  directive  POBSTTS  defines  the  data  values  for  a  user  defined  dependent  variable  var.  The 
POINTS  directive  must  have  appeared  within  a  THRUPUT  directive  before  being  used.  If  it  has 
not  appeared  previously  in  a  THRUPUT  statement,  then  the  POINTS  data  is  not  processed  and 
a  warning  message  will  be  given  by  the  dbc.  The  THRUPUT  directive  defines  the  functionality 
of  dependent  variable  var  and  ultimately  defines  the  number  of  data  points  that  must  be  read 
by  the  POINTS  directive.  By  default,  data  points  are  read  with  the  independent  variables  set  to 
their  first  defined  values,  then  incremented  through  each  independent  variable  range  using  the 
independent  variable  names  as  defined  from  right  to  left.  That  is,  the  order  will  be  as  follows 
for  a  generic  THRUPUT  variable: 

var(bptn, bpts,  bpt2,  bpti).  (3) 

The  last  data  value  can  be  terminated  with  a  forward  slash  (/),  but  is  not  necessary.  For  example, 
if  a  dependent  variable  Z  has  the  following  THRUPUT  and  VARBPT  definitions: 

thruput  Z(  X,  Y) 

X  varbpt  0.0  2.0  4.0  5.0/ 

Y  varbpt  0.0  6.0  13.0  17.0/ 

Z  points  0.0  1.0  2.0  3.0  4.0  5.0  6.0  7.0  8.0  9.0 
10.0  11.0  12.0  13.0  14.0  15.0/. 

These  values  would  be  assigned  to  Z(X,Y)  as  follows: 


1 

Z(  0.0, 0.0)  =  0.0 

9 

Z(  4.0, 0.0)  =  8.0 

2 

Z(  0.0, 6.0)  =  1.0 

10 

Z(  4.0, 6.0)  =  9.0 

3 

Z(  0.0, 13.0)  ==  2.0 

11 

Z(  4.0, 13.0)  =  10.0 

4 

Z(  0.0, 17.0)  =  3.0 

12 

Z(  4.0, 17.0)  =  11.0 

5 

Z(  2.0, 0.0)  =  4.0 

13 

Z(  5.0, 0.0)  =  12.0 

6 

Z(  2.0, 6.0)  =  5.0 

14 

Z(  5.0, 6.0)  =  13.0 

7 

Z(  2.0, 13.0)  =  6.0 

15 

Z(  5.0, 13.0)  =  14.0 

8 

Z(  2.0, 17.0)  =  7.0 

16 

Z(  5.0, 17.0)  =  15.0. 

This  order  may  be  reversed.  The  option  of  data  order  is  given  because  of  the  data  order  con¬ 
vention  of  FORTRAN  and  C  being  opposite  to  one  another.  The  data  order  option  is  only  a  user 
personal  issue  and  does  not  affect  the  fimctionality  of  the  database  and  compiler.  If  reversed, 
the  -r  flag  MUST  be  used  when  compiling  the  database  with  dbc.  The  THRUPUT  variable  will 
be  processed  in  the  following  order: 

var(bpti,  bptj,  bpts, ...,  bptn).  (4) 
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4  DATABASE  COMPILER  -  dbc 


A  compiler  has  been  written  to  generate  either  FORTRAN  77  or  C  source  code  routines  to  read 
and  interpolate  databases  using  the  database  format  described  in  section  3.  These  routines  are 
designed  to  be  easily  accessed  from  user  code.  The  name  of  the  database  compiler  is  dbc  and 
its  function  is  described  in  the  following  sections. 


4.1  Usage 

dbc  [-be [F I W] dDruv  -in[s|l]  -o  name]  database_name  ... 
dbc  -dT[F|C] 


4.2  Description 

The  dbc  command  compiles  dbc  database  format  files  into  FORTRAN  77  or  C  source  code.  This 
source  code  allows  the  database  to  be  read  and  interpolated  from  a  user's  own  FORTRAN  77  or 
C  programs  with  a  mimmum  of  interface  requirements.  The  input  database  may  have  any  file 
name.  The  use  of  a  .db  extension  is  suggested  however. 


4.3  Command  Line  Flag  Options 

-b  Generate  the  binary  database  from  the  ASCII  input  database  without  creating  any  source 
code  to  read  or  interpolate  the  database.  This  is  useful  only  when  the  data  in  the  database 
has  changed  or  multiple  databases  are  to  be  read  from  one  source  file,  i.e.  the  first  database 
is  compiled  normally,  then  the  remainder  is  compiled  with  the  -b  flag.  This  prevents  pre¬ 
viously  generated  dbc  source  code  from  being  overwritten. 

-C  Translate  database  to  C  for  C  interfacing.  Also  creates  a  binary  database  file  and  Hbraries. 
The  memory  for  the  database  will  be  dynamically  allocated  at  run-time.  Can  be  used  with 
the  -F  flag.  See  -CF  option. 

-CF  Translate  database  to  C  for  FORTRAN  77  interfacing.  This  is  the  default  translation  method. 
Also  creates  a  binary  database  file  and  libraries.  The  memory  for  the  database  will  be  dy¬ 
namically  allocated  at  run-time. 

-CW  Translate  database  to  C  for  Microsoft  Windows  interfacing.  Also  creates  a  binary  database 
file  and  libraries.  The  memory  for  the  database  will  be  dynamically  allocated  at  run-time. 

-d  Make  all  interfacing  routines  have  variables  of  double  precision  type. 

-D  Turn  on  debug  mode.  Debug  mode  produces  an  extended  listing  of  information  useful  for 
tracking  down  problems  during  compilation  of  database  files. 

-F  Translate  database  to  FORTRAN  77  for  FORTRAN  77  interfacing.  The  -CF  option  is  more 
efficient  for  FORTRAN  77  code  interfacing.  Similar  to  the  -C  and  -CF  options,  this  option 
also  creates  a  binary  database  file  and  libraries.  However,  libraries  are  still  written  in  C 
because  the  binary  database  file  is  created  in  C  binary.  Can  be  used  with  the  -C  flag.  See 
-CF  option. 

-TIF  I C]  Generate  a  FORTRAN  77  or  C  test  program  and  database  respectively.  This  test  database 
can  then  be  compiled  with  dbc  to  create  the  read  and  interpolation  routines. 
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-m[s  |1]  Selects  the  type  of  memory  model  to  use  when  generating  the  database  read  routines. 
The  small  memory  model  uses  data  statements  in  FORTRAN  77,  or  variable  initialisation 
in  C,  to  store  the  database  values.  This  should  only  be  used  for  small  database  files  (one¬ 
dimensional  and  two-dimensional  THRUPUT  dependent  variables  only)  and  removes  the 
overhead  of  reading  data  files  at  run-time.  The  large  memory  model  creates  a  binary  file 
from  the  ASCII  input.  This  binary  file  is  read  when  the  database  initialisation  routine  is 
called  at  run-time.  A  binary  file  is  used  for  its  compactness  and  speed  of  reading.  The 
default  is  the  large  memory  model. 

-o  name  Name  of  the  generated  output  source  code  file.  If  this  option  is  not  used,  the  name  of 
the  first  database  input  file  is  used  to  create  the  name  the  output  file. 

-r  Process  THRUPUT  independent  variables  from  the  left-most  independent  variable  moving 
to  the  right.  The  default  is  to  process  from  right  to  left.  This  option  effects  the  order  in 
which  the  POINTS  data  should  be  written  to  the  ASCII  database  file.  See  section  3.4. 

-u  Include  underscore  extension  to  all  C  interfacing  routines.  This  is  used  for  FORTRAN  77 
compilers  that  may  append  underscores  to  procedural  names  during  compilation.  Link¬ 
ing  errors  will  occur  if  underscores  are  appended  and  this  option  is  not  used. 

-V  Verbose  toggle.  Default  is  on.  Verbose  provides  more  information  during  compilation  of  a 
database  source  file  than  would  normally  be  given.  Information  about  what  files  are  being 
compiled,  the  names  of  libraries  being  created,  and  the  way  the  user  should  compile  the 
resultant  source  files  is  given.  If  turned  off  and  there  are  no  errors  in  the  database  file,  then 
no  information  about  the  process  will  be  seen  on  successful  completion. 


4.4  Compilation  of  dbc 

The  program  dbc  is  written  in  ANSI  C  and  will  compile  on  most  systems  without  problems. 
However,  some  system  dependent  definitions  are  required  to  overcome  some  differences  in  the 
way  individual  systems  pass  variables  between  routines,  especially  when  mixing  FORTRAN  77 
and  C  code.  The  dbc  source  code  allows  the  definition  of  operating  system  types.  On  compila¬ 
tion  of  dbc,  at  least  one  of  the  following  system  types  must  be  defined. 

AIX  For  IBM  R6000  AIX  machines  using  cc  and  xlf. 

IRIX  For  Silicon  Graphics  IRIX  machines  using  cc  and  f77. 

MSDOS  For  IBM  PC  or  Microsoft  Windows  using  Borland  C  and  Lahey  F77L.  The  FORTRAN  77 
translation  will  only  work  correctly  with  Lahey  F77L. 

For  example,  to  compile  the  dbc  source  code  for  AIX,  the  following  command  should  be  used: 
cc  -O  dbc.c  -DAIX  -o  dbc 


4.5  Interpolation/Extrapolation  Algorithm 

The  interpolation/extrapolation  algorithm  employed  in  the  database  compiler  is  based  on  a  lin¬ 
ear  method.  It  is  able  to  interpolate  in  an  arbitrary  number  of  dimensions  so  long  as  the  data  for 
the  dimensions  exist.  At  present  a  limit  of  fifteen  dimensions  has  been  placed  on  the  compiler 
to  prevent  possible  over-run  of  memory.  A  defined  THRUPUT  dependent  variable  of  fifteen 
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dimensions  would  take  a  large  amoimt  of  data  to  define.  For  example,  if  a  fifteen-dimensional 
dependent  variable  were  defined  with  independent  variables  that  had  five  data  points  per  di¬ 
mension,  then  there  would  be  approximately  3.05  x  10^°  points  to  define  in  the  POINTS  di¬ 
rective.  Thus  far,  the  maximum  dimension  defined  in  an  actual  application  by  a  user  has  been 
seven. 

To  explain  how  the  linear  interpolation  scheme  works,  consider  figure  1  which  sets  out  the  ter¬ 
minology  for  a  one  dimensional  interpolation.  Let  x  be  the  value  found  by  interpolation;  xi  and 


/l 


/2 


-0- 


X 


X. 


Figure  1:  One-dimensional  Interpolation 


X2  are  the  closest  values  to  x.  Let  /i  and  /2  be  the  values  returned  by  f(xi)  and  f(x2)  respec¬ 
tively.  Let  Xri  and  Xrs  be  the  ratios  of  the  distances  between  x  and  $i,  x  and  X2  as  follows: 


X 


ri 


X 


rz 


X  —  Xi 
X2  -  Xi 

1  . 


(5) 


Then  f{x)  is  given  by  the  equation: 

fix)  =  aJrs/l  +  ®ri  /2-  (6) 

This  example  is  fairly  trivial,  but  increasing  the  example  to  a  two-dimensional  interpolation 
adds  complexity.  The  two-dimensional  situation  is  illustrated  in  figure  2.  Let  x  and  y  be  the  val¬ 
ues  required  to  interpolate  /(®,  y).  Let  xi,  yi,  $2,  and  y2  be  the  closest  values  to  x  and  y.  Let  /i, 
/2,  fs,  and  /4  be  the  values  returned  by  /{xi,  yi),  /(x2,  yi),  /(si,  y2)/  and  f{x2,  y2)  respectively. 
Let  Xri  and  x^^  be  the  ratios  of  the  distance  between  x  and  xi,  x  and  X2  as  shown  in  equation  5. 
Also  let  y^z  and  y^j  be  the  ratios  of  the  distance  between  y  and  yi,  y  and  y2  as  follows: 


2/ri 

yra 


y-yi 
y2  -  yi 
1  -  yri  etc. 


(7) 


To  interpolate  for  /(x,  y),  the  intermediate  values  a  and  b  need  to  be  known  and  are  evaluated 
as  follows: 


a=/(«,yi)  =  ®r2/l+®ri/2  (8) 

b  —  fix^yf)  —  3:^2 /s  "b  Xrj /4. 

The  point  /(x,  y)  can  now  be  evaluated  as  follows: 

/(a:,y)  =  yrsO  +  yri^* 

~  y»'2  (®r2/l  ”b  ff)  "b  yri  (®r2/3  "b  Xf^  f/f] 
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Figtire  2:  Two-dimensional  Interpolation 


—  Vr^  ®r2  /l  +  2/r2  ®ri  /2  +  J/ri  ®r2  /s  +  J/ri  ®ri  /4 
2  2  2  2 

=  /i  n  + /2  n  + A  n  a., + a  n  u,, 

j=i  i=i  j-i 

=  E(/»n/ni)  (9) 

t=i  j=i 

where  f^-  denotes  the  corresponding  axis  ratio  for  the  j*'*  dimension  at  the  node  (a  node 
being  one  of  the  edge  data  points  to  be  interpolated).  Extending  equation  9  to  Ti-dimensions 
produces: 


2n  ^ 

/(®.y)  =  EC/ill/ni)  (10) 

i=l  i=l 

where  n  is  the  dimensionality  of  the  function  to  interpolate  and  2'^  is  the  number  of  closest  boimds 
to  sum  with  their  corresponding  axis  ratios. 


4.6  Interfacing  dbc  Generated  Code  with  User  Code 

To  assist  in  learning  how  to  interface  user  code  with  the  database  read  and  interpolation  rou¬ 
tines,  dbc  may  be  used  to  produce  a  test  database  and  test  programs  for  FORTRAN  77  or  C  with 
the  commands  dbc  -TF  and  dbc  -TC  respectively.  The  test  database  that  is  created  illustrates 
how  the  database  may  be  used  to  convert  a  binary  number  into  a  decimal  number  and  is  called 
dbcsample.dat.  The  aim  of  the  test  database  is  to  illustrate  most  of  the  features  that  can  be  in¬ 
cluded.  It  also  provides  a  platform  on  which  users  can  quickly  build  their  own  code.  The  test 
database  is: 


TITLE  Binary  to  decimal  converter 

★ 
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THRUPUT  BinToDec(  bitl,  bit2,  bit3,  bitl,  bitl,  bitl),tst 


•k 


bitl  VARBPT  0,1/  Ibl  =  0  ubl  =  1 

bit2  VARBPT  0,1/  Ibl  =  0  Ibv  =  -10.0  ubl  =  1  ubv  =10.0  warn=on 

bits  CONBPT  0,1,1/ 


BinToDec  POINTS 

0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20, 

21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40, 

41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60, 

61,62,63/ 


This  test  database  defines  one  six-dimensional  dependent  variable  BinToDec.  Most  of  the  in¬ 
put  fields  to  BinToDec  are  a  function  of  independent  variable  bitl  which  has  values  0  and  1 
as  given  by  the  independent  variable  directive  VARBPT.  The  upper  bound  limit  directive  states 
that  if  bitl  ever  exceeds  a  value  of  1,  then  that  value  will  be  replaced  with  1.  Likewise  the 
lower  botmd  limit  directive  states  that  if  bitl  ever  falls  below  a  value  of  0,  then  that  value  will 
be  replaced  with  0.  This  means  that  bitl  will  never  be  extrapolated  past  these  two  boundaries. 

The  independent  variables  bit2  and  bit3  are  given  for  example  only  and  are  not  required  in 
the  conversion  from  binary  into  decimal,  bit 2  shows  how  the  upper  and  lower  bound  value 
directive  operates.  If  bit 2  exceeds  the  upper  bound  value  of  1,  then  the  returned  value  from 
the  THRUPUT  dependent  variable  BinToDec  will  be  10.0.  Likewise  if  the  lower  boimd  limit  of 
0  is  reached,  a  value  of  -10.0  is  returned.  Note  also  that  the  warning  directive  has  been  turned 
on  with  warn=on.  This  means  that  a  warning  message  will  be  displayed  whenever  the  upper 
or  lower  boimd  limits  are  reached. 

The  independent  variable  bit 3  is  defined  with  the  constant  independent  variable  directive 
CONBPT.  Although  not  required,  it  states  that  bitl  will  have  values  0  through  1  in  steps  of  1 
(i.e.  only  values  0  and  1).  No  extra  directives  have  been  placed  on  bit3  which  indicates  that 
values  entered  at  this  level  may  be  extrapolated  to  infimty. 

All  the  data  for  BinToDec  are  listed  after  the  POINTS  directive.  Here  the  data  are  ordered  such 
that  the  rightmost  independent  variable  in  the  THRUPUT  directive  is  varied  most  quickly.  A 
flag  option  exists  in  the  dbc  compiler  if  the  reverse  order  is  required. 

To  compile  this  test  database  one  of  the  following  commands  would  be  used,  depending  on 
whether  a  FORTRAN  77  or  C  interface  is  required: 


dbc  -F  dbcsample.dat  !  FORTRAN  77  for  FORTRAN  77 
dbc  -CF  dbcsample.dat  !  C  for  FORTRAN  77  interface 
dbc  -C  dbcsample.dat  !  C  for  C  interface 
dbc  -CW  dbcsample.dat  !  C  for  Microsoft  Windows  interface. 


The  first  command  will  generate  FORTRAN  77  read  and  interpolation  routines  for  use  with 
FORTRAN  77  source  code.  This  command,  although  still  available,  has  been  superseded  largely 
by  the  second  command  that  creates  C  read  and  interpolation  routines  for  a  FORTRAN  77  in¬ 
terface.  The  reason  is  that  the  C  routines  can  manage  the  database  memory  requirements  better 
through  dynamic  allocation.  This  allows  database  files  to  be  loaded  and  imloaded  as  required. 
The  last  two  commands  generate  routines  in  C  for  C  user  source  code. 

After  compilation  a  binary  form  of  the  database  will  be  generated  and  called  dbcsample.bin.  The 
database  initiahsation  and  BinToDec  interface  routines  will  be  written  either  to  dbcsample.f  or 
dbcsample.c.  The  initialisation  routine  has  the  following  naming  convention: 
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ini  t_(ib_<  input_dat  abas  e_name  > 


The  <input_database_name>  is  taken  from  the  dbc  command  line  and  will  not  include  the  file 
extension.  Therefore,  in  this  example  the  initialisation  routine  will  be  called  init-dbAhcsample. 
The  initialisation  routine  is  responsible  for  reading  the  binary  database  file  and  manipulating 
the  data  ready  for  use  by  the  interfacing  routines.  In  this  example,  only  one  THRUPUT  de¬ 
pendent  variable  was  defined  and  the  interface  to  BinToDec  will  be  called  BinToDecJst.  The 
extension  of  Jst  was  defined  at  the  end  of  the  THRUPUT  directive. 

To  read  this  database,  two  test  programs  may  be  generated  called  dbctest.f  and  dbctest.c.  The 
FORTRAN  77  and  C  test  programs  are: 


c 

C  DBC  FORTRAN  test  program 

C 

program  cJbctest 

real  f,  rl,  r2,  r3,  r4,  r5,  r6 

call  ini t_db_dbc sample 
do  while  (  .TRUE.) 

write(  6,  '(a,$)')  'Enter  six  bits  (e.g.  010001)  ::  ' 

read(  5,  *)  rl,  r2,  r3 ,  r4,  r5,  r6 
f  =  BinToDec_tst(  rl,  r2,  r3 ,  r4,  r5,  r6) 
write(  6,  *)  'Decimal  =  ',  f 

write(  6,  *)  'Return  bits  =  ',  rl,  r2,  r3,  r4,  r5,  r6 
write (  6,  *) 
enddo 
end 


/* 

DBC  C  test  program 

*/ 

# include  <stdio.h> 

#include  "dbcsample.h" 

void  main(  void) 

{ 

float  f,  rl,  r2,  r3,  r4,  r5,  r6; 

init_db_dbcsample ( ) ; 
while  (1)  { 

printf{  "Enter  six  bits  (e.g.  0  1  0  0  0  1)  ::  " )  ; 
scanf(  ''%f  %f  %f  %f  %f  %f",  &rl,  &:r2 ,  &r3 ,  &r4,  &r5,  &r6)  ; 
f  =  BinToDec_tst(  Sri,  &r2,  &r3 ,  &r4,  &r5,  &r6)  ; 
printf(  "Decimal  =  %f\n",  f ) ; 

printf(  "Return  bits  =  %f  %f  %f  %f  %f  %f\n\n",  rl,  r2,  r3,  r4,  r5,  r6); 

} 

) 


In  the  test  programs,  only  two  procedural  calls  are  used  to  interface  with  the  database  routines. 
The  first  is  initJbJbcsample  which  reads  the  database  into  memory.  The  second  is  BinToDecJst 
which  is  the  routine  that  interfaces  to  the  interpolation  routine.  Note  that  in  the  C  interface  these 
values  must  be  passed  by  pointer  so  that  if  any  upper  or  lower  bound  limit  directives  are  used, 
the  return  values  can  be  passed  back  to  the  user  code.  Table  1  gives  the  result  of  input  to  this 
sample  program. 
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Input 

Result 

Comment 

0 

1 

0 

0 

0 

1 

17 

Normal  conversion 

1 

0 

1 

0 

1 

0 

42 

1 

1 

1 

1 

1 

1 

63 

n 

0 

1.1 

0 

0 

0 

1 

10 

Test  of  upper  bormd  limit  on  bit 2 

1 

0 

1000 

0 

0 

1 

8033 

Test  of  'infinite'  extrapolation  on  bit 3 

Table  1:  dbc  Sample  Test  Program  Results 


4.7  Multiple  Database  Access 

The  database  compiler  dbc  has  been  written  to  allow  easy  access  to  multiple  databases  by  one  of 
two  methods.  The  first  uses  a  nested  IF  block  structure  to  select  between  the  different  databases. 
The  second  uses  a  technique  of  making  the  THRUPUT  section  of  each  database  common,  thus 
requiring  only  one  interpolation  structure. 


4.7.1  Nested  IF  block  method 

This  method  compiles  each  required  database  and  generates  unique  initiafisation  routines  for 
each.  To  access  a  database,  the  initialisation  routine  for  that  database  is  called  once  only  at  the 
beginning  of  the  program,  then  the  required  THRUPUT  dependent  variable  defined  is  accessed 
using  the  interface  routine.  For  example,  for  the  following  database  files: 


flllc.db,  flS.db 


the  following  database  initialisation  routines  would  be  created  with  dbc: 


init_db_f 111c ( ) 
init_db_fl8 ( ) . 


Each  database  in  this  case  must  have  unique  THRUPUT  dependent  variable  names  otherwise 
the  compiler  will  not  be  able  to  determine  which  variable  should  be  called.  The  user  then  must 
create  the  required  code  structure  to  select  and  interface  between  the  four  databases.  This  means 
that  the  F-lllC  and  F/A-18  databases  would  have  a  lift  coefficient  interface  routine  as  follows: 


if  (  Fill)  then 

call  init_db_f 111c { ) 

CL  =  CL_F111(  ALT,  MACH,  DELHT,  ALPHA,  SWEEP) 

else  if  (  F18)  then 
call  init_db_f 18 ( ) 

CL  =  CL_F18(  ALT,  MACH,  ALPHA,  STAB) 


endif 
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4.7.2  Common  THRUPUT  Method 


The  second  method  can  only  be  used  with  the  C  libraries  for  FORTRAN  77  or  C  interfaces  only. 
This  method  accesses  multiple  databases  through  a  single  initialisation  routine  and  definition 
of  interpolation  variables  using  one  interface  structure.  That  is,  rather  than  using  CLJFlll  and 
CL-F18  as  shown  in  the  previous  example,  a  single  name  of  CLJFLT  could  be  used.  This  is  achieved 
by  making  the  databases  have  a  common  THRUPUT  section  by  looking  for  similarities  in  the 
THRUPUT  dependent  variables  required  for  interpolation.  For  example,  the  previous  exam¬ 
ple  has  one  thing  in  common;  they  are  all  aircraft  databases.  Therefore  it  is  logical  to  assume 
that  the  THRUPUT  dependent  variables  required  to  define  the  aircrafts'  characteristics  would 
be  similar.  The  F-lllC  database  has  a  THRUPUT  definition  for  Uft,  drag  and  pitching  moment 
coefficients  as  follows: 

THRUPUT  CL(  ALT,  MACH,  DELHT,  ALPHA,  SWEEP ),FLT 
THRUPUT  CDLB(  MACH,  SWEEP ),FLT 

THRUPUT  CM(  ALT,  MACH,  DELHT,  ALPHA,  SWEEP ),FLT 

The  F/  A-18  aircraft  has  the  following  THRUPUT  structure  for  the  same  dependent  variables: 

THRUPUT  CL(  ALT,  MACH,  ALPHA,  STAB),FLT 
THRUPUT  CDLB(  MACH),FLT 

THRUPUT  CM(  ALT,  MACH,  ALPHA,  STAB),FLT 

The  main  differences  between  these  two  structures  is  that  the  F-lllC  aircraft  has  an  extra  pa¬ 
rameter  of  SWEEP;  and  the  stabilator  and  angle  of  attack  independent  variables  (DELHT,  STAB, 
ALPFIA),  are  reversed.  These  two  structures  can  be  made  equivalent  by  firstly  swapping  the 
ALPHA  and  DELHT  independent  variables  in  the  F-lllC  aircraft  database  (making  sure  that 
this  is  reflected  in  the  POn^S  directive  for  all  independent  variables  swapped),  as  follows: 

THRUPUT  CL(  ALT,  MACH,  ALPHA,  DELHT,  SWEEP), FLT 
THRUPUT  CDLB(  MACH,  SWEEP), FLT 

THRUPUT  CM(  ALT,  MACH,  ALPHA,  DELHT,  SWEEP), FLT 

The  F/ A-18  THRUPUT  structure  must  have  the  same  dimensionality  as  the  F-lllC  THRUPUT 
structure.  This  can  be  achieved  with  the  NULL  independent  variable  directive  in  the  following 
manner: 


THRUPUT  CL(  ALT,  MACH,  ALPHA,  STAB,  NULL), FLT 
THRUPUT  CDLB(  MACH,  NULL), FLT 

THRUPUT  CM(  ALT,  MACH,  ALPHA,  STAB,  NULL), FLT 

The  NULL  independent  variable  directive  has  no  size  and  has  no  effect  on  the  data  defined  in 
the  POINTS  directive.  It  merely  serves  to  add  an  extra  dimension  to  the  interfacing  routines  at 
the  location  it  is  defined. 

Once  all  required  database  files  have  the  same  THRUPUT  struchore,  one  must  be  compiled  to 
generate  the  initialisation  and  interface  routines.  All  other  database  files  can  be  compiled  to 
generate  the  binary  data  file  only  and  they  are  read  at  run  time.  If  the  F-lllC  database  file  is 
compiled,  it  will  generate  an  initialisation  file  called  initJb/lllc.  This  routine  will  be  structured 
as  follows: 


void  init_db_f 111c (  void) 
{ 


int  nbp,  ntp; 
FILE  *fp; 
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if  (  ver_notdone)  { 

printf(  "Database  Compiler  V-2.6\n''); 
ver_notdone  =  FALSE; 

) 

printf (  "Initialising  \ " f lllc\ " \n" ) ; 
printf  (  "  Fine  Database  Version  1.0\n"); 

if  ((  fp  =  fopen(  "flllc.bin",  "rb"))  ==  NULL) 
error_msg(  2,  "flllc.bin",  NULL) ; 
if  (  fread(  &nbp,  sizeofi  int) ,  1,  fp)  !=  1) 
error_msg(  4,  "cl_flt",  (char  *)  NULL) ; 
if  (  fread(  &ntp,  sizeof(  int),  1,  fp)  !=  1) 
error_msg(  5,  "cl_flt",  (char  *)  NULL) ; 
if  (  fread(  levels_cl_flt,  sizeof(  int),  5,  fp)  !=  5) 
error_msg(  6,  "levels",  "cl_flt"); 
if  (  bp_cl_flt  !=  NULL) 
f ree (  bp_cl_flt)  ; 

if  ((  bp_cl_flt  =  (float  *)  calloc(  nbp,  sizeof(  float)))  ==  NULL) 
error_msg(  7,  "brealtpoint" ,  "cl"); 

if  (  fread(  bp_cl_flt,  sizeof(  float),  nbp,  fp)  !=  nbp) 
error_msg(  1,  “breakpoint",  "cl"); 
if  (  tp_cl_flt  !=  NULL) 
free(  tp_cl_flt) ; 

if  ((  tp_cl_flt  =  (float  *)  calloc(  ntp,  sizeof(  float)))  ==  NULL) 
error_msg (  7 ,  " thruput ",  “ cl " ) ; 

if  (  fread(  tp_cl_flt,  sizeof(  float),  ntp,  fp)  !=  ntp) 
error_msg (  1 ,  " thruput ",  " cl ' " ) ; 


More  THRUPUT  variables  to  be  read. 


if  (  fclose(  fp)  !=  0) 

error_msg(  3,  "flllc.bin",  NULL) ; 

} 

To  make  this  a  generic  routine  able  to  read  all  the  aircraft  databases  in  the  example/  the  initial¬ 
isation  routine  would  be  renamed  to  something  like  initAh.  All  references  to  flllc  oiflllc.bin 
must  be  replaced  with  a  C  character  pointer  dhname.  The  pointer  dbname  must  be  declared  as  an 
argument  to  initAb  by  replacing  (  void)  with  char  *dbname.  The  new  initialisation  routine  would 
then  be  structured  similar  to  the  following  code: 


void  init_db(  char  *dbname) 

{ 

int  nbp,  ntp; 

FILE  *fp; 

if  (  ver_notdone)  { 

printf (  "Database  Compiler  V-2.6\n"); 
ver_notdone  =  FALSE  ,- 

} 

printf (  "Initialising  \"%s\"\n",  dbname); 

if  ((  fp  =  fopen(  dbname,  "rb"))  ==  NULL) 
error_msg (  2,  dbname,  NULL) ; 

if  (  fread(  &nbp,  sizeof(  int),  1,  fp)  !=  1) 
error_msg(  4,  "cl_flt",  (char  *)  NULL) ; 

if  (  fread(  &ntp,  sizeof(  int),  1,  fp)  !=  1) 
error_msg(  5,  "cl_flt",  (char  *)  NULL) ; 

if  (  fread(  levels_cl_flt,  sizeof(  int),  5,  fp)  !=  5) 
error_msg(  6,  "levels",  "cl_flt"); 
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if  (  bp_cl_flt  !=  NULL) 
free(  bp_cl_flt) ; 

if  ((  bp_cl_flt  =  (float  *)  calloc(  nbp,  sizeof (  float)))  ==  NULL) 
error_msg(  7,  "brealcpoint" ,  "cl”); 

if  (  fread(  bp_cl_flt,  sizeof (  float),  nbp,  fp)  !=  nbp) 
error_msg(  1,  "brealcpoint" ,  "cl"); 
if  (  tp_cl_flt  !=  NULL) 
free(  tp_cl_flt) ; 

if  ((  tp_cl_flt  =  (float  *)  calloc(  ntp,  sizeof (  float)))  ==  NULL) 
error_msg(  7,  "thruput",  "cl"); 
if  (  fread(  tp_cl_flt,  sizeof (  float),  ntp,  fp)  !=  ntp) 
error_msg (  1 ,  " thruput ",  ” c 1 " ) ; 


More  THRUPUT  variables  to  be  read. 


if  (  fclose(  fp)  !=  0) 

error_insg(  3,  dbname,  NULL)  ; 

} 

User  code  can  now  access  the  required  aircraft  database  using  the  following  FORTRAN  77  code: 

character* 12 8  dbname 
character*!  NULL 

NULL  =  char(  0) 

write(6, ' (a, $) ' )  'Enter  database  name  (flllc/fl8)  ::  ' 
read (5, ' (q,a) ' )  lengthdbn,  dbname 

call  init_db(  dbname (  lilengthdbn)  //  '.bin'  //  NULL) 
cl  =  cl_flt(  alt,  mach,  alpha,  stab,  sweep) 

The  same  sequence  would  be  used  with  C  code.  However  the  appending  of  a  NULL  character 
would  not  be  necessary.  It  is  only  required  when  passing  character  strings  from  FORTRAN  77  to 
C  routines.  This  method  completely  removes  the  need  for  the  complex  IF  block  structure  shown 
in  the  first  method. 


5  EXAMPLE -F-lllC  DATABASE 

Appendix  A  gives  an  example  of  part  of  the  database  format  used  for  the  F-lllC  flight  dynamic 
model.  Each  line  of  the  database  example  will  be  explained.  The  line 

TITLE  F-lllC  MODEL  DATABASE  LONGITUDINAL  V-1 . 1  trial  only  4/10/1993 

is  setting  the  title  to  the  database  and  has  no  influence  over  the  method  for  reading  the  database. 
The  first  of  the  THRUPUT  commands  is: 

THRUPUT  CL ( SWEEPB , ALT2 , MACHH , DELHT2 , ALPHAB ) 

and  defines  a  dependent  variable  called  CL  (lift  coefficient)  which  is  a  function  of  aircraft  sweep 
(SWEEPB),  altitude  (ALT2),  mach  number  (MACHH),  horizontal  stabilator  deflection  (DELHT2), 
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and  angle  of  attack  (ALPHAB).  SWEEPB,  ALT2,  MACHH,  DELHT2,  and  ALPHAB  are  known 
as  independent  variables.  These  variables  define  the  functionality  of  dependent  variable  CL. 
The  number  of  points  required  to  be  read  at  the  POINTS  directive  is  defined  with  either  the 
CONBPT  or  VARBPT  directive.  The  independent  variable  definition  for  SWEEPB  is  given  by 
the  line: 

SWEEPB  VARBPT  16.0,26.0,35.0,45.0,50.0, 

72 . 5/LBL=16 . 0 , UBL=72 . 5 

This  indicates  that  the  dependent  variable  CL  has  database  values  for  sweep  angles  of  16°,  26°, 
35°,  45°,  50°,  and  72.5°  and  therefore  has  six  values  on  this  axis.  The  options  LBL  and  UBL  state 
that  the  database  for  sweep  should  not  be  extrapolated  below  16°  or  above  72.5°  respectively. 
Similarly,  CL  has  values  for  altitude  at  5, 10, 20, 30,  and  40  thousand  feet  given  by  the  VARBPT 
directive  as  follows: 


ALT2  VARBPT  5000.0,10000.0,20000.0,30000.0, 
40000.0/LBL=5000.0,UBL=40000.0 


The  same  method  for  reading  can  be  applied  to  independent  variables  MACHH  and  DELHT2 
which  have  thirteen  and  five  values  for  their  respective  axes.  Independent  variable  ALPHAB 
however  shows  the  use  of  a  CONBPT  directive  as  follows: 


ALPHAB  CONBPT  -4 . 0 , 20 . 0 , 2 . 0 /LBL=-4 . 0 , UBL=2 0 . 0 

The  dependent  variable  CL  will  therefore  have  values  for  angle  of  attacks  of  -4°  through  20°  in 
2°  increments  to  give  thirteen  values  on  this  axis.  Multiplying  the  number  of  values  for  each  of 
the  independent  variable  axes  together  will  give  the  number  of  data  points  that  need  to  be  read 
at  the  POINTS  directive  for  CL.  The  number  of  data  points  to  be  read  for  CL  is  25  350,  calculated 
as  follows: 

SWEEPB  ALT2  MACHH  DELHT2  ALPHAB 

6  X  5  X  13  X  5  X  13  =  25  350 


The  values  for  CL  are  read  with  the  POINTS  directive  and  are  given  as: 


CL  POINTS 


-0.760058999, 

0.026981026, 

0.562229216, 


-0.563299000, 

0.223740995, 

0.595377624, 


-0.366538972, 

0.394610941, 

0.595377624, 


-0,169778988, 

0.498090923, 

0.595377624, 


Partial  data  shown  only. 


0.074630000, 

0.490870029, 

0.887478352, 


0.178690001, 

0.594930053, 

0.952275097 


0.282750010, 

0.698989987, 


0.386810005, 

0.803050041, 


The  order  in  which  these  data  points  are  allocated  for  CL  is  as  follows.  First,  all  independent 
variables  SWEEPB,  ALT2,  MACHH,  DELHT2,  and  ALPHAB  are  set  to  their  first  defined  val¬ 
ues.  Subsequent  points  are  read  by  incrementing  through  the  rightmost  defined  independent 
variable  (ALPHAB)  imtil  its  last  value  is  reached.  The  next  independent  variable  to  the  left 
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(DELHT2)  is  incremented  by  one  value  and  the  right  most  independent  (ALPHAB)  set  back  to 
its  first.  The  right  most  independent  variable  (ALPHAB)  is  again  incremented  to  its  last  value. 
This  system  continues  imtil  all  independent  variables  have  been  processed  through  their  ranges. 
This  is  illustrated  in  the  following  table. 


Point 

SWEEPS 

ALT2 

MACHH 

DELHT2 

ALPHAB 

Value 

1 

16.0 

5000.0 

0.0 

-25.0 

-4.0 

-0.760058999 

2 

16.0 

5000.0 

0.0 

-25.0 

-2.0 

-0.563299000 

3 

16.0 

5000.0 

0.0 

-25.0 

0.0 

-0.366538972 

4 

16.0 

5000.0 

0.0 

-25.0 

2.0 

-0.169778988 

5 

16.0 

5000.0 

0.0 

-25.0 

4.0 

0.026981026 

. 

. 

. 

. 

25346 

72.5 

40000.0 

1.8 

10.0 

12.0 

0.594930053 

25347 

72.5 

40000.0 

1.8 

10.0 

14.0 

0.698989987 

25348 

72.5 

40000.0 

1.8 

10.0 

16.0 

0.803050041 

25349 

72.5 

40000.0 

1.8 

10.0 

18.0 

0.887478352 

25350 

72.5 

40000.0 

1.8 

10.0 

20.0 

0.952275097 

6  CONCLUSION 


A  database  format  and  compiler  used  in  the  development  of  aircraft  flight  dynamic  model  databases 
within  AOD  at  DSTO-AMRL  has  been  presented.  Information  on  both  the  syntax  and  method 
of  reading  the  database  format  has  been  included.  A  comprehensive  explanation  of  the  inter¬ 
polation  technique  used  by  the  database  compiler  has  also  been  presented.  An  example  F-lllC 
database  file  has  been  used  to  illustrate  the  techniques  involved. 
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Appendix  A  -  F-lllC  Database  Format  Example 


TITLE  F-lllC  MODEL  DATABASE  LONGITUDINAL  V-1 . 1  trial  only  4/10/1993 

★ 

THRUPUT  CL ( SWEEPB , ALT2 , MACHH , DELHT2 , ALPHAS ) 

THRUPUT  CM ( SWEEPB , ALT2 , MACHH , DELHT2 , ALPHAS ) 

THRUPUT  TR ( SWEEPA , ALTl , MACHA , ALPHAS , DELHTl ) 

THRUPUT  CDMIN ( SWEEPA , MACHA ) 

THRUPUT  CLMIN ( SWEEPA , MACHA ) 

THRUPUT  CLBR( SWEEPA, MACHA) 

THRUPUT  CDLB ( SWEEPA , MACHA ) 

THRUPUT  CDLS ( SWEEPA , MACHA) 

THRUPUT  CMQ( SWEEPB, MACHH, ALPHAS) 

THRUPUT  CMAD( SWEEPB, MACHH, ALPHAB) 

THRUPUT  CLQ(SWEEPB, ALPHAB, MACHH) 

THRUPUT  CLAD (SWEEPB, MACHH, ALPHAB, ALT3) 

THRUPUT  CLAH(MACHF) 

* 

ALPHAB  CONBPT  -4 . 0, 20 . 0 , 2 . 0/LBL=-4 . 0,UBL=20 . 0 
SWEEPA  VARBPT  16 . 0 , 26 . 0 , 35 . 0 , 50 . 0 , 72 . 5/LBL=16 . 0 , UBL=72 . 5 
SWEEPB  VARBPT  16 . 0 , 26 . 0 , 35 . 0 , 45 . 0 , 50 . 0 , 72 , 5/LBL=16 . 0 , UBL=72 . 5 
MACHA  VARBPT  .0,. 4, .6, .7, .8, .85, .9, .95, 1.0, 

1.2,1.58,1.6,2.0,2.07,2.2,2.5 /LBL=0 . 0 , UBL=2 . 5 
MACHF  VARBPT  0.0,0.2,0.4,0.6,0.8,0.9,0.95,1.0, 

1.05,1.1, 1.2, 1.6, 2. 0,2.5 /LBL=0.0,UBL=2 .5 
MACHH  VARBPT  0.0, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0, 

1.1,1.2,1.4, 1.5,1.8/LBL=0.0,UBL=1.8 
ALTl  VARBPT  0 . 0 , 15000 . 0 , 35000 . 0 , 50000 . 0 , 60000 . 0/LBL=0 . 0 , UBL=60000 . 0 
ALT2  VARBPT  5000 .0, 10000 .0,20000.0,30000.0, 40000 . 0/LBL=5000 . 0,UBL=40000 . 0 
ALT3  VARBPT  0.0,5000.0,10000.0,20000.0,30000.0,40000. 0/LBL=0 . 0 , UBL=40000 . 0 
DELHTl  VARBPT  -25 . 0 , -10 . 0 , -4 . 0 , 0 . 0 , 4 . 0 , 10 . 0/LBL=-25 . 0 , UBL=10 . 0 
DELHT2  VARBPT  -25 . 0 , -10 . 0 , 0 . 0 , 4 . 0 , 10 . 0/LBL=-2 5 . 0 , UBL=10 . 0 
★ 

CL  POINTS 

-0.760058999,  -0.563299000,  -0.366538972,  -0.169778988, 

0.026981026,  0.223740995,  0.394610941,  0.498090923, 

0.562229216,  0.595377624,  0.595377624,  0.595377624, 


Partial  data  shown  only. 


0.074630000,  0.178690001,  0.282750010,  0.386810005, 
0.490870029,  0.594930053,  0.698989987,  0.803050041, 
0.887478352,  0.952275097 

CM  POINTS 

0.697396994,  0.709969878,  0.722542644,  0.735115528, 
0.747688353,  0.760261118,  0.773426414,  0.787884593, 
0.791329622,  0.779234648,  0.747074664,  0.690322995, 


Partial  data  shown  only. 


-0.091829039,  -0.156257093,  -0.229905427,  -0.304699570, 
-0.380075365,  -0.455472916,  -0.530332088,  -0.604088902, 
-0.676181197,  -0.747301221 
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